JCSM Shareware Collection 1996 September/JCSM Shareware Collection (JCS Distribution) (September 1996).ISO/butility/hotop.zip/HOTOP.DOC

Text File | 1993-10-20 | 27KB | 599 lines

HOT OPERATOR --

Unattended PC Production Job Scheduling

Network Ready/Multi-User



NOTES:

The application Hot Operator and this document are:

Copyright 1992
Joey Robichaux.

For ordering information, see the accompanying ORDER.FRM file.

Hot Operator is distributed as shareware -- this means I encourage users to
share copies of this product with their associates for their evaluation.
Users may freely use and evaluate Hot Operator.  However, after a 30 day
evaluation period, you must purchase a copy of Hot Operator to continue
use.


ASSOCIATION OF SHAREWARE PROFESSIONALS

This program is produced by a member of the Association of Shareware
Professionals (ASP).  ASP wants to make sure that the shareware principle
works for you. If you are unable to resolve a shareware-related problem
with an ASP member by contacting the member directly, ASP may be able to
help. The ASP Ombudsman can help you resolve a dispute or problem with an
ASP member, but does not provide technical support for members' products.
Please write to the ASP Ombudsman at 545 Grover Road, Muskegon, MI 49442 or
send a CompuServe message via CompuServe Mail to ASP Ombudsman 70007,3536.


Trademarks:

Dr. Switch is a trademark of Black and White International
SwapDos is a trademark of Innovative Data Concepts.




WHAT IS HOT OPERATOR?


What it's not -->  Hot Operator is NOT a menu program
                   Hot Operator is NOT a wakeup routine.


What it is    -->  Hot Operator runs production job schedules.  It can run
                   jobs directly at the touch of a key, or it can schedule
                   jobs to run a specific times or even certain days of
                   the week.  It can schedule jobs to run at intervals --
                   you may want a data collection routine to run every 30
                   minutes.  It can also check for "successful" job
                   completion.  If the job did not complete successfully, it
                   can automatically be scheduled to run again.

                   Hot Operator runs multi-user on your network.  This lets
                   you run Hot Operator on a dedicated PC at a remote user
                   site, yet your technical operations staff can still
                   maintain the job schedule in-house.

What it needs -->  Hot Operator uses a dedicated PC; it will not run in the
                   background while the PC is used for other purposes.
                   Furthermore, Hot Operator really needs a memory swapping
                   device to be most effective (see the section on MEMORY
                   SWAPPING).  Hot Operator has built-in memory swapping
                   capability (you can turn this on or off) -- or your
                   individual system configuration may require you to use
                   a third party memory swapper.

What it does  -->  Hot Operator maintains a list of production jobs.  A job
                   contains a statement to be issued from a DOS prompt.
                   This statement will be issued at the appropriately
                   scheduled time.


Case Example 1:

ABC Industries recently installed a client-server based order taking
system.  The information systems staff and the order-taking crew are in two
separate buildings in two different cities.  However, all are attached to
local networks connected via a WAN.

Users enter orders all day at their workstations; the databases live on
a UNIX-based SQL database attached to the network.  At 4:30 pm each day,
order takers leave for the day.  However, someone must run a set of
production jobs that do posting, inventory maintenance, and management
reporting.

Information Systems cannot run this production -- the databases are in a
different city and communications over the WAN would be too slow.  The
order-takers do not want to stay late to run the production schedule and
local management does not want to hire an operations staff.

ABC Industries orders HOT OPERATOR and plans to run it on a dedicated
work-station at the order-taker's site.  The HOT OPERATOR databases are
installed on a subdirectory on the file server.  Since HOT OPERATOR data
lives on the networked file server, Information Systems staff can build and
maintain production schedules and jobs remotely via multi-user access.
They schedule jobs to begin running at 11:00pm.

At 11:00pm, HOT OPERATOR kicks off the appropriate sequence of jobs.
Certain jobs only run on Friday evenings, others run every weekday night.
There's even a special cross-network upload that only runs on Sunday nights.

At first, the entire production schedule runs fine on the single dedicated
PC.  As the production load grows, things get a little tight.  It's
difficult for one workstation to complete the nightly production jobs.

Information Systems decides to try some "trickery" and "spread" the
night-time load among some of the idle workstations at the order-taker
site.

They split the production schedule into three pieces.  Instead of adding
two more copies of HOT OPERATOR, they write two batch files that check for
the existence of a certain file.  If the file isn't found, the batch
file loops and then rechecks for the file.  When the file is detected,
the batch file branches and begins a production schedule.  These two
batch files are installed on two of the faster order-taker PC's.  When
the order takers leave at 4:30, they start the batch files.

At 11:00 pm, HOT OPERATOR kicks off its production schedule.  The first
thing it does is create the "certain file" the other two PC's have been
waiting for.  It then continues to run its part of the production
schedule.  All three PC's are now in gear!

It takes Information Systems several days before they get the work schedule
split up evenly enough to load all machines equally.  Since HOT OPERATOR is
a networked application that can be changed remotely, this is quite easy
to do!


Case Example 2:

Critical Industries uses Hot Operator to schedule all their after-hours
production runs.  These production runs must run at the end of the day
after all daily on-line transactions are complete.

Recently, some employees have begun staying late to enter transactions.
Since production should not run until after daily transactions, Critical
cannot reliably use time scheduling to run production -- you can't start
production at 6:00 pm unless you're sure all daily transactions are
complete.

Critical decided to use the environment variable checking feature within
Hot Operator.  First, they instructed the group of users who were
staying late to run a special "logout" procedure when they were through
for the day.  This logout procedure built a dummy file called START.NOW
on the file server.

Next, they added a FILEEXIST statement to the beginning of their
main production batch file, MAINPROD.BAT.  This statement checks for the
existence of START.NOW.  If START.NOW is not found, the batch file
terminates.  If START.NOW is found, the batch file continues and runs
production.  After productions is finished, START.NOW is deleted and the
environment variable ALLDONE is set to "T".

Finally, they edited the MAINPROD.BAT record within Hot Operator and
added ALLDONE as the environment variable.  The left the starting time
for MAINPROD.BAT as 6:00 pm.

At 6:00 pm, Hot Operator issues the command MAINPROD.BAT.  This command
begins and checks for the existence of START.NOW.  If START.NOW isn't
found, the command terminates without setting ALLDONE to "T".

Control returns to Hot Operator.  Since ALLDONE is not set, Hot Operator
reschedules MAINPROD.BAT to try again in a few minutes.  This sequence
continues.

At 7:30 pm, the employee group is finally finished with their online
transactions.  They logout with their special "logout" procedure and the
file START.NOW is created on the file server.

At 7:31, Hot Operator tries MAINPROD.BAT again.  This time it finds
START.NOW, so it continues through the entire production job schedule.
At the end of the production run, START.NOW is deleted and ALLDONE is
set to "T".  These DOS commands look like this:

        DEL F:\HOME\START.NOW
        SET ALLDONE=T

Hot Operator receives control -- this time it senses that ALLDONE is set
to T.  It marks MAINPROD.BAT as complete and does NOT reschedule the
job.

Note -- If the environment variable ALLDONE was not available (and it might
not be), then Critical Industries could have used the FILE NAME field in
the Hot Operator record to check for file existence and accomplish the same
thing.


Case Example 3:

Unattended Corp also uses Hot Operator for their nightly and weekend
production scheduling.

One Monday morning, Unattended realized that the weekend production had
not finished due to bad data.  Since they were using file name checking
to ensure completion, Hot Operator had faithfully rescheduled and
retried their production jobs all weekend -- only to have them fail each
time because of the bad data.

Unattended wants to continue to run unattended -- they don't want to
schedule weekend operations staff to monitor production -- but they
would like someone notified if jobs are not successful.

They write a small counting program in Basic and add this program to
their production batch job.  Everytime the job runs, it adds one to a
counter.  If the counter reaches 10, the job terminates with an
ERRORLEVEL code of 10.

Unattended doesn't make any changes to their Hot Operator job record.
Hot Operator continues to check the environment variable and reschedules
their production jobs if necessary.

If the job continues to bomb, Hot Operator continues to reschedule the
job.  After the tenth time, the counter program reaches 10 and
terminates with an ERRORLEVEL of 10.  The next statment in the batch
file senses the ERRORLEVEL and branches to a routine that sends an
autodial string to a modem.  The modem then dials the pager number of
the person "on call" that weekend -- this alerts the "on call" person of
problems with the production jobs and gives Unattended Corp plenty of
time to solve the problems before Monday morning.


INSTALLING HOT OPERATOR:

HOT OPERATOR must run on a dedicated PC.  Although HOT OPERATOR will run in
less than 640K conventional RAM, you should have at least 640K RAM
installed, plus you should ideally have 1 to 2 meg of EMS/EEMS if you want
to take advantage of memory swapping routines (discussed later).  In
particular, you should have at least 510,000 free bytes of conventional
memory before you start HOT OPERATOR.

Although HOT OPERATOR runs on a dedicated PC, it should be installed to a
networked drive, not to the local drive.  If you install HOT OPERATOR on a
local drive, you lose the ability for multiple users to access the same set
of data.  Thus, while HOT OPERATOR will work fine if installed on a
local drive, you lose the benefits of multi-user access.

To install, create a HOT OPERATOR subdirectory on the appropriate drive.
Copy all the HOT OPERATOR files to this subdirectory.

Make that subdirectory current if it is not.  Type "HOTOP" and press Enter.


RUNNING HOT OPERATOR

Hot Operator is "pick list" driven.  It presents a scrolling pick list of
currently defined jobs.

Use the up and down arrows to move the highlighted select bar up or down
the picklist.  If you move all the way to the bottom of the window, the
jobs will "scroll" to the next job.

Use the PgUp and PgDn keys to page forwards or backwards a screen at a
time.  The Home key and the End key bring you to the first record or the
last record in the list.

Insert new records by pressing the INSERT key; edit existing records by
highlighting the record and pressing the ENTER key; delete existing records
by highlighting a record and pressing the DELETE key.

You can tell Hot Operator to NOT try and release jobs by pressing the F3
Schedule Toggle key.  This is really handy when you're spending some time
building your Hot Operator job schedule records and you don't want to release
jobs before you're really ready for them.  This is also nice if you're running
on a remote PC across the network against the Hot Operator files and you don't
want a job released.

You can "hot" execute a job by highlighting the existing record and
pressing the F2 key.  When you "Hot Execute" a job, you don't affect its
scheduling features -- for instance, if a job is scheduled to run once a day
and you "Hot Execute" it, the job will STILL be scheduled to run.  The
date/time last executed fields are NOT filled in when you Hot Execute a job.

The F1 key offers "Help" when you're working on a job record.  You can
"quit" Hot Operator by pressing the ESCAPE key.


SCHEDULING NOTES

Note that job records scheduled to run once a day will ONLY run once a
day!

The reason is that Hot Operator keeps track of the last time and day a
job executed.  If it senses a job has already executed, it will not
reschedule the job (except for interval jobs).

If you edit a job record and change either the command or the start
time, then Hot Operator considers this to be a "new" job record.  Being
a new record, it could not have been issued previously.  Therefore, Hot
Operator will set the last date and time executed to blanks.  The record
then becomes a candidate for execution.

If you need a job scheduled to run more than once a day and you cannot
use interval scheduling, you must create more than one job record --
each job record can reference the same production job.

Next note:  Suppose you have a job scheduled to run at 8:00 and a job
scheduled for 9:00 -- but you don't start Hot Operator till 10:00.  What
happens?

The first time Hot Operator checks the job list (about a minute after it
starts), it will schedule both the 8:00 AND the 9:00 jobs to run.

Which will it run first?  Not necessarily the 8:00 job -- Hot Operator always
runs jobs in Job Index order.  Therefore, whichever job comes first in the
list -- regardless of the time it is scheduled for -- will run first!


JOB RECORDS

A Job record contains these fields:

Job:            A six character Job identifier.  This field controls the
                sort sequence in the scrolling picklist.  It is the first
                field that appears in the scrolling picklist.  Since HOT
                OPERATOR checks the jobs sequentially, you can use this
                field to fine-tune the sequence of job execution.

                Hot Operator recognizes a "special" job name -- _ZRET_.
                (That's "underscore Z R E T underscore").  If you create
                a job record with this name, Hot Operator will always
                issue _ZRET_'s associated command after every command it
                issues.

                This is particularly handy if you need to build a
                special purpose cleanup sequence that should always run
                -- for example, a batch file that returns to the Hot
                Operator drive and directory (See the IMPORTANT section
                at the end of this document.)

                You can also use the _ZRET_ record to create your own
                special job logging (although Hot Operator does perform
                job logging).

                Note that Hot Operator will issue the _ZRET_ identified
                command EVEN if the day fields are blank.  In fact, this
                is a good "safety" feature to ensure that _ZRET_ is
                never inadvertantly time or interval scheduled.

Desc:           A short job description.  This field also appears in the
                scrolling picklist.

DOS COMMAND:    The command to be issued at the scheduled time.  This can
                be any command you can issue at a DOS prompt.  For example,

                        DIR B:*.* /p    or
                        C:\WORK\POSTING         or
                        D:\LOTUS\LOTUS
                        COMMAND /C DOALL.BAT

                Most of the time, you'll probably create batch commands
                to start your jobs.  If you have problems running batch
                files, try the last format shown above:
                "COMMAND /C FILENAME.BAT".

                If your job needs more than a minimum of conventional RAM,
                you should use either Hot Operator's built-in memory
                swapping capability or a third-party software memory
                swapping device (discussed later).

                If you receive a "RUN ERROR", this is because you have
                insufficient conventional RAM for job swapping.  You
                must have at least 510,000 bytes of conventional RAM
                available before you start Hot Operator -- even if
                you're using memory swapping.

SMTWTFS:        These are seven different fields.  They correspond with the
                seven days of the week.  Place an "X" or a space in these
                fields.  Use an "X" if you which the job to run on that
                day; use a space to exclude the job from running that day.

TodoTime:       What time do you want the job to run?  Use a military 24:00
                clock, ie: 11:00 pm = 23:00.

Interval:       How often should the job run?  How many minutes between
                runs?  You can use this in combination with the TodoTime
                field -- for example, nothing will happen until the
                TodoTime, at which point the job will be scheduled to run
                every "Interval" minutes.

Environ Var:    Do you want to check for successful completion?  If so, add
                a DOS statement to the end of your job that issues a SET to
                this environment variable.  For example,

                        SET RANOKAY=T

                Set this variable to T for success, or anything else for
                failure.  Enter this variable name in the Environment
                Variable field.  Hot Operator checks whether or not this
                variable is set to T.  If not, Hot Operator reschedules the
                job to run again in a few minutes.

                Since Hot Operator "shells" when it issues commands, it
                makes "copies" of the environment space.  These copies
                disappear when shelling completes -- this normally means
                that environment changes to the copied environment aren't
                reflected in the original environment.  The result is that
                environment checking will NOT work for all users.  These
                users should use "File Name" checking instead (See next field).

File Name:      This can be used instead of "Environ Var" to check for
                successful completion.  If you are using a memory swapping
                device, it's possible that the environments are also swapped.
                If this happens, it's very difficult to pass environment
                variable information.  If you enter a valid DOS file name
                in this field, Hot Operator will check for the existence
                of this file.  If the file is not found, Hot Operator will
                reschedule the job to try again.

Memory Swap:    Hot Operator can do its own memory swapping.  Set this field
                to "Y" and Hot Operator will swap itself out of conventional
                RAM to EMS, XMS, or a temporary disk file.  It then issues
                the "DOS COMMAND" field.  After the DOS COMMAND completes,
                Hot Operator loads itself back in and resumes.

                The good part about this is that memory swapping frees up
                the maximum available conventional RAM for your DOS COMMAND.

                Memory swapping sounds like a no-brainer -- who wouldn't want
                the maximum available conventional RAM?  Why make this a
                Y or N field?

                The reason is that there are a couple of "gotchas" --
                first, memory swapping may be a little slow (especially
                if you're swapping to a temporary disk file).
                Therefore, if your command can run in a minimum of RAM,
                it's faster to leave this set to "N".

                The second "gotcha" is that Hot Operator's memory
                swapping may simply not work -- or not work effectively
                -- in your machine configuration.  Memory managment is a
                complex and "non-standard" beast -- if your unique
                machine configuration and memory management are such that
                Hot Operator does not work effectively when it tries to
                memory swap, you may need to use a more flexible and
                tunable third party memory swapper.

                Finally, if Hot Operator is unable to swap to EMS or
                XMS, it uses a temporary disk swap file.  As mentioned,
                disk swapping is slow.  Also, it's possible these
                temporary disk files may not always be erased (for
                example, when a job crashes and does not return properly
                to Hot Operator).  You may have to clean these files up
                manually.  The files are usually between 300K and 500K;
                they have single word names made up of nonsense
                characters -- for instance, "AIDDBCTA".

Longterm:       This field can be either blank, "M", "Q", or "Y".  If this
                field is non-blank, then it is combined with the following
                field.  Use these two fields to schedule a job on a specific
                date of the month ... or a specific day of the current
                quarter ... or a specific day of the year.  Thus, you can
                schedule a job to run on the 165th day of the year ... or the
                14th day of the quarter ... of the 3rd day of every month.

Longamt:        This field can be either a number or the letter "E".  If
                this field is a number, then it is combined with the previous
                field (if it's non-blank) to denote which day of the period
                to schedule the job.  Thus, a Longterm of "Q" and a Longamt of
                87 means "Run this job on the 87th day of every quarter".  If
                you want to schedule jobs to run on the end of a period, then
                put an "E" in this field (since end of period days vary).



MEMORY SWAPPING

(NOTE: This section assumes you are NOT using Hot Operator's built-in memory
swapping capability)

When Hot Operator executes a job, it "shells" to DOS and issues the
command.  When Hot Operator "shells" to DOS, it leaves a copy of itself in
conventional RAM.  This means you'll usually have much less than 640K in
which to run your production jobs.  In fact, all you'll normally be able to
do are some simple DOS commands.

Because of this, Hot Operator contains an internal memory swapper.  However,
Hotnet also supports and encourages the use of other software memory swapping
devices. This lets you use the product that works best with your configuration.

Two popular memory swapping products are Dr. Switch by Black and White
International and SwapDos by Innovative Data Concepts.  SwapDos is a
shareware product.  Both allow memory swapping to various places (expanded
memory, extended memory, or even hard disk space)

Here are examples of both products:


USING DR. SWITCH

Install Dr. Switch and make sure a copy of DRSWITCH.EXE is accessible from
the Hot Operator subdirectory.  To memory swap using Dr. Switch, enter the
DOS COMMAND in the Hot Operator record like this:

                DRSWITCH xyz

This command will use Dr. Switch to swap Hot Operator out of conventional
RAM.  It then executes the job "xyz".  When "xyz" is finished, Dr. Switch
swaps Hot Operator back into conventional RAM.  This frees up the maximum
available conventional RAM.

You can use Dr. Switch to execute .EXE and .COM files; you can also execute
batch files.  You don't need to use any type of EXIT command at the end of
your job; ordinary job termination returns control to Hot Operator.


USING SWAPDOS

SwapDos is slightly more flexible than Dr. Switch.  SwapDos will let you
set "marks" in memory; you can then swap everything after a certain mark.
This lets you do things like temporarily removing unneeded TSR's.

You can also use SwapDos without marks.  To do this, enter this command in
the DOS COMMAND field:

                        SWAPDOS xyz

This swaps Hot Operator out of conventional ram and then executes the
program "xyz".



SECURITY MODE

Some sites need to "protect" the job definitions; they don't want anyone
editing the job definitions other than approved people.

To lock Hot Operator out of edit mode, just begin Hot Operator with any
dummy parameter.  For example:

                HOTOP X

This will ignore all edit, insert, or delete requests.  The job scheduling
will still occur, and users can still "hot" execute jobs by highlighting
them and pressing ENTER.


JOBLOG

Hot Operator keeps a "log" of commands and the times they are issued.  This
log is created automatically.

The log name is "JOBLOG.TXT".  It will be found on the subdirectory current
to Hot Operator.  It contains commands issued both at scheduled times and
times issued through the F2 manual override.

This log will continue to grow as commands get issued.  You may want to
create a scheduled job that deletes this log once a week or so.


IMPORTANT NOTES

The most common problem incurred with Hot Operator is this:

A user builds batch files that switch to other subdirectories.  Hot Operator
executes these batch files.  However, the batch files neglect to return to
the Hot Operator subdirectory!

The next time Hot Operator tries to execute a scheduled command, it searches
in the current subdirectory.  If the previous command did not return to the
Hot Operator subdirectory, Hot Operator MAY NOT find the appropriate command.

Furthermore, since Hot Operator always logs "JOBLOG.TXT" to the current
subdirectory, you may end up with multiple copies in different subdirectories!

Because of this, it's recommended you ALWAYS return to the Hot Operator drive
and directory after each scheduled command!  (The special job "_ZRET_" can
be a handy tool to help you do this -- see the JOBNAME section above)


ADDRESSES:

For more information on Dr. Switch:

        Black and White International
        P. O. Box 1040
        Planetarium Station
        New York, N.Y.  10024-0541
        phone: [phone]


For more information on SwapDos:

        Innovative Data Concepts
        1657 The Fairways
        Suite 101
        Jenkintown, PA 19046
        voice: [phone]
        fax:   [phone]
        Compuserve: 75300,564